1. Field of the Invention
The present invention relates to the field of computer security, and more specifically relates to controlling the software which may be run on a computer.
2. Background of the Invention
The distribution of malicious software has plagued computer networks since the days of electronic bulletin board systems (BBSs). While these publicly accessible sites allowed users to exchange software, it was well understood that untrusted software could be malicious. As a rule of thumb software downloaded from a BBS was not installed on essential computer systems unless it was somehow determined to be safe.
Today the Internet dominates computing, and because connectivity and interoperability are essential systemic qualities, malicious software has become an even more pernicious problem. Web sites provide mobile code, such as ActiveX controls and signed Java applets, which can be seamlessly, and often transparently, installed on a computer and executed through a common Web browser. While such software may enhance the multimedia experience, create a more interactive environment, or provide other positive benefits, the same technology allows software to be written which locates and destroys documents. Documents accessible to such software include not only those stored on the computer on which the software is installed, but also those available across the network to which the computer belongs.
In addition to Web browser based malicious software, users also run programs received via E-mail for entertainment, without knowing what the program will do, or its origin in the world. Other executables can masquerade as data, donning, for example, DOC, GIF, and JPEG file extensions, and causing their own type of damage.
A study by Computer Economics of Carlsbad, Calif., found that in the first two quarters of 1999 alone, businesses worldwide lost more than $7.6 billion to malicious software. Additionally, well-publicized events involving the Melissa virus, the Explorer.zip worm, and BackOrifice clients contribute to an atmosphere of crisis. Organizations may respond to these threats by adopting policies prohibiting software download or installation, but, in practice, organizations have little control over this activity.
The idea of restricting application execution has been explored by some in the prior art, but none adequately addresses issues of strong security and easy administration. Some in the prior art allow administrators to set up rules for local computers, which define times during which programs can be executed, and by whom such programs may be executed. In addition, the prior art has introduced the concept of rejecting unknown applications.
However, those in the prior art have several weaknesses which render them inadequate. For example, those rejecting unknown applications base the determination of which applications are known solely on the application's executable name. This system allows even a novice user to bypass the security system by naming a malicious application after an approved one. In addition, many in the prior art provide inadequate administrative support over a user community. For example, the prior art only allows administration on a per-machine basis, and policies must be defined explicitly for each user.
Others in the prior art have taken a different approach to control of executable software. In those products, cryptographic hashes of critical files are maintained and periodically verified. An application on the computer periodically checks the critical files, and if changes are detected, an administrator may be notified. This technology is used primarily for intrusion detection. However, execution control is not combined with error checking, thus an executable that has been compromised by a virus (and has therefore had its signature altered) will be allowed to execute until the system has detected this change and an administrator has removed the compromised executable. A significant amount of damage could be done before the problem is detected.